Mirrors build_and_test.sh's summary-block format but uses the Linux
UnrealBuildTool / UnrealEditor-Cmd binaries, builds the host project's
Editor target on the Linux platform, and exports LD_LIBRARY_PATH at
the third-party install dirs (RuntimeDependencies aren't staged on
Linux editor builds, so the plugin's libmujoco / lib_coacd / libzmq
aren't otherwise dlopen-able).

Note: the existing build_and_test.sh hardcodes Win64 binary names and
a Win64 build platform, so the Linux invocation in CONTRIBUTING.md
would currently fail. Whether this should be a parallel _linux.sh or
a unified platform-detecting script is an open question; see URLab-Sim#45.

Refs: URLab-Sim#45

URLab stored TCHAR_TO_UTF8 macro output in a long-lived `const char*`,
which dangles immediately because the macro expands to a pointer into
a temporary FTCHARToUTF8 whose lifetime ends at the end of the full
expression.

On Windows/MSVC the stack memory often still held the original bytes
when the pointer was used a few lines later, so the bug went
unnoticed. On Linux/clang the stack is reclaimed aggressively and the
pointer dereferences garbage. Two consequences observed on Linux:

- FMujocoSpecWrapper::AddDefault registered each <default> class
  under a corrupted name, so subsequent mjs_findDefault lookups by
  the joint/geom/actuator import paths failed silently and MuJoCo
  fell back to its built-in defaults. This caused all five
  Linux-only test failures from the previous run:
    URLab.Import.DefaultClassJointAxis
    URLab.Import.DefaultFromTo
    URLab.Import.RoundTrip_Defaults
    URLab.Muscle.Arm26_ActuatorParams
    URLab.Muscle.Arm26_Counts
  After this fix all 177 URLab.* tests pass on Linux.

- UMjTendon::RegisterToSpec did the same thing with the side-site
  string for <tendon><geom .../></tendon> wrapping. No failing test
  caught it but the pattern is identical so it's fixed here too.

Both call sites now construct an explicit FTCHARToUTF8 with
function-scope lifetime so the converted bytes outlive the
mjs_addDefault / mjs_wrapGeom call.

Refs: URLab-Sim#45

…RPATH

UBT's auto-computed RPATH for the URLab plugin .so on Linux resolves
incorrectly when the plugin lives outside the host project tree (e.g.
symlinked in from a separate clone). The relative path it emits is

  ${ORIGIN}/../../../../../UnrealEngine/../URLabTest/Plugins/.../lib

which resolves to a non-existent /home/<user>/URLabTest/... rather than
the plugin's real on-disk location. Result: the loader can't find
libmujoco / lib_coacd / libzmq at editor startup, so the plugin module
fails to load without LD_LIBRARY_PATH.

Side-step the relative-path issue by symlinking third-party shared libs
into the plugin's own Binaries/Linux/ directory after build. UBT already
adds ${ORIGIN} to the plugin .so's RPATH (correctly, this time), so the
loader finds the libs in the same dir as the plugin .so. No
LD_LIBRARY_PATH needed at editor or packaging time.

Changes:
- URLab.Build.cs (Linux branch): drop the broken
  PublicRuntimeLibraryPaths.Add(<absolute path>) entries (they end up
  generating bad RPATH); use RuntimeDependencies with $(BinaryOutputDir)
  target so packaging stages the libs alongside the plugin .so. Glob
  *.so* (not just *.so) so SONAME-versioned real files like
  libmujoco.so.3.7.0 also get staged.
- Scripts/setup_runtime_linux.sh: new helper that symlinks
  third_party/install/<pkg>/lib/*.so* into Binaries/Linux/ for editor
  builds (where RuntimeDependencies aren't auto-staged on Linux).
  Idempotent.
- Scripts/build_and_test_linux.sh: invoke setup_runtime_linux.sh after
  the plugin builds, drop the LD_LIBRARY_PATH fallback (no longer
  needed).

After: editor launches and the URLab.* automation suite runs to
177/177 passing with LD_LIBRARY_PATH unset.

Refs: URLab-Sim#45

… libzmq.a

Stop directly editing the CoACD submodule's public/coacd.h. Instead
overlay a fixed copy via the existing CoACD_custom/ pattern that
URLab already uses for CMakeLists.txt + cmake/. The fixed copy
relaxes `#if _WIN32` to `#if defined(_WIN32)` so consumers compiled
with `-Wundef -Werror` (UE on Linux) accept the header without
warnings becoming errors. Both build.sh and build.ps1 grow a
parallel block to copy CoACD_custom/public/* onto src/public/.

Also disable libzmq's static archive on Linux (BUILD_STATIC=OFF).
The static archive's mailbox_safe.cpp pulls libc++
condition_variable_any::wait_until -> pthread_cond_clockwait via
inlining, which UE's link sysroot can't resolve. The .so version
links its own runtime deps internally and works fine, so the static
lib is unused and only causes the URLab plugin link to fail
(undefined symbol pthread_cond_clockwait). Restricted to Linux via a
case on uname so the Windows path is unchanged.

After both changes: 177/177 URLab.* automation tests still pass on
Linux from a clean third-party rebuild.

Refs: URLab-Sim#45

Replace the "Linux is experimental" line in the README requirements
with a pointer to docs/linux_setup.md, mention the Linux build
script alongside the Windows one in the install section, and add
the new doc to the mkdocs nav under Guides.

The new docs/linux_setup.md captures:

- Prerequisites: UE 5.7 Linux binary, CMake 3.24+, host UE5 C++
  project with the plugin in Plugins/.
- Why a special build flow: UE's bundled clang + libc++ require
  ABI-compatible third-party libs, so the system gcc + libstdc++
  default of build_all.sh produces unlinkable binaries.
- The full env-var sandwich (CC/CXX/AR/RANLIB/CFLAGS/CXXFLAGS/LDFLAGS)
  pointing the third-party CMake builds at UE's clang.
- The role of Scripts/setup_runtime_linux.sh in staging the third-
  party .so files into Binaries/Linux/ so $ORIGIN-RPATH resolves
  them without LD_LIBRARY_PATH.
- How to run the automation suite via Scripts/build_and_test_linux.sh,
  including the editor-must-be-closed gotcha.
- A short list of known caveats (plugin must be inside the host
  project's Plugins/, first-launch shader compile time, etc.).

Refs: URLab-Sim#45

Accept --engine <UE_ROOT> on third_party/build_all.sh. When given on
Linux, glob Engine/Extras/ThirdPartyNotUE/SDKs/HostLinux/Linux_x64/
v*_clang-*/x86_64-unknown-linux-gnu so the script survives UE version
bumps (v26 -> v27) without a script edit, then export
CC / CXX / AR / RANLIB and the matching CFLAGS / CXXFLAGS / LDFLAGS
internally so child build.sh invocations inherit them.

Replaces the explicit env-var sandwich docs/linux_setup.md previously
asked the user to type. The new flow is a single command:

    ./third_party/build_all.sh --engine $UE_ROOT

Without --engine the script falls through to the host toolchain
(unchanged behaviour for Windows / macOS, and for any Linux user who
deliberately wants the system gcc + libstdc++).

Why this matters: with the wrong toolchain, system gcc + libstdc++
either produces .so files whose C++ ABI doesn't match UE's plugin
link (wall of std::* undefined-symbol errors), or — worse, with some
combinations — emits LTO bitcode objects that masquerade as .so but
fail to load with a cryptic "file too short" at editor startup.
Both are real failure modes that cost real debugging time.

Each MuJoCo / CoACD / libzmq build.sh now invokes
Scripts/setup_runtime_linux.sh after install on Linux. This catches
the partial-rebuild case: bumping a single submodule SHA and running
only that dep's build.sh (skipping build_all.sh and
build_and_test_linux.sh) would otherwise leave Binaries/Linux/ holding
stale symlinks pointing into the wiped install/<dep>/lib/ — the editor
fails to load with no obvious cause.

setup_runtime_linux.sh now warn-and-skips with exit 0 when
Binaries/Linux/ doesn't exist yet, so a first-time fresh checkout
(third-party built before the plugin .so) doesn't error out. The next
plugin build creates Binaries/Linux/, the next setup_runtime_linux.sh
call (from any of the build paths) populates it.

Linux-only block — guarded with `if [ "$(uname -s)" = "Linux" ]` —
so Windows / macOS paths are unchanged.

linux_setup.md previously assumed a working $UE_ROOT. Add a short
"Unreal Engine 5" subsection at the top of Prerequisites covering:

- where to get the precompiled Linux binary (epicgames.com/linux)
- the .zip flow (~25 GB compressed, ~43 GB extracted)
- disk-space rule of thumb (~70 GB free for initial setup including
  shader / DDC cache)
- display options for headless servers (NICE DCV / X2Go / VNC)
- common apt prereqs (libsdl2, libvulkan1) for fresh Ubuntu 22.04

Mentions the source-build path exists but is not required (most
users land on this page from a fresh distro and don't realise the
binary distribution exists).

Per review feedback: bash globs sort lexicographically, so
`for cand in $SDK_BASE/v*_clang-*/...; do ... break; done` picks
v25 over v26 when both exist. Latent today since UE ships exactly
one Linux toolchain per engine version, but it would silently
regress on a future UE bump if a transitional engine ever shipped
two.

Replace the loop with `ls -d ... | sort -V | tail -1` (version-aware
sort, picks the highest) and keep the executability check.

Per review feedback on docs/linux_setup.md:

1. Add a source-build option (UnrealEngine clone + Setup.sh +
   GenerateProjectFiles.sh + make UnrealEditor) under Prerequisites.
   The precompiled binary is still recommended as the path of least
   friction; the source build is for engine-level debugging.

2. Split the doc into clearly-labelled sections:
   - One-time setup (the existing 4-step walkthrough)
   - Day-to-day workflow (just `git pull` + build_and_test_linux.sh)
   - Troubleshooting / Advanced (build flags reference, env-var
     sandwich for manual per-dep rebuilds, known caveats).

   The Reviewer's read was that the doc currently looked like a
   first-setup guide with no signposting for what the loop is after
   that. Now there's a header pointer at the top and the day-to-day
   section is its own anchor.

3. Move the "Build flags applied internally" reference list out of
   step 1 (where most users won't need it) and into Troubleshooting /
   Advanced — it's debugging context, not setup material.

No content removed, just reshelved.